United States Patent and Trademark Office 



UNITED STATES DEPARTMENT OF COMMERCE 
I nilid Stall-, l'atint and Trademark Office 

Address: COMMISSIONER FOR PATENTS 



APPLICATION NO. | FILING DATE |j HRST NAMED INVENTOR | ATTORNEY DOCKET NO. | CONFIRMATION NO. 

10/699,102 10/31/2003 Shuichi Takagi 50T5441.01 2678 

EXAMINER 
LE, MIRANDA 
ART UNIT "I PAPER NUMBER 

'MAIL DATE | DELIVERY MODE 

05/12/2008 PAPER 

Please find below and/or attached an Office communication concerning this application or proceeding. 

The time period for reply, if any, is set in the attached communication. 



27774 7590 05/12/2008 

MAYER & WILLIAMS PC 
251 NORTH AVENUE WEST 
2ND FLOOR 
WESTFIELD, NJ 07090 



PTOL-90A (Rev. 04/07) 



l/ffflrC? nVrliUli Otfff Iff ids y 


Application No. 

10/699,102 


Applicant(s) 

TAKAGI ET AL. 


Examiner 

MIRANDA LE 


Art Unit 

2167 





- The MAILING DATE of this communication appears on the cover sheet with the correspondence address — 
Period for Reply 



A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) OR THIRTY (30) DAYS, 
WHICHEVER IS LONGER, FROM THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time may be available under the provisions of 37 CFR 1 .136(a). In no event, however, may a reply be timely filed 
after SIX (6) MONTHS from the mailing date of this communication. 

- If NO period for reply is specified above, the maximum statutory period will apply and will expire SIX (6) MONTHS from the mailing date of this communication. 

- Failure to reply within the set or extended period for reply will, by statute, cause the application to become ABANDONED (35 U.S.C. § 133). 
Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any 
earned patent term adjustment. See 37 CFR 1 .704(b). 

Status 

1 )KI Responsive to communication(s) filed on 28 January 2008 . 
2a )^ This action is FINAL. 2b)D This action is non-final. 

3) D Since this application is in condition for allowance except for formal matters, prosecution as to the merits is 

closed in accordance with the practice under Ex parte Quayle, 1935 CD. 11, 453 O.G. 213. 

Disposition of Claims 

4) ^ Claim(s) 1-14 is/are pending in the application. 

4a) Of the above claim(s) is/are withdrawn from consideration. 

Claim(s) is/are allowed. 

6) ^ Claim(s) 1-14 is/are rejected. 

7) 0 Claim(s) is/are objected to. 

8) D Claim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) Q The specification is objected to by the Examiner. 

10) D The drawing(s) filed on is/are: a)D accepted or b)D objected to by the Examiner. 

Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1.85(a). 
Replacement drawing sheet(s) including the correction is required if the drawing(s) is objected to. See 37 CFR 1.121(d). 

1 1) D The oath or declaration is objected to by the Examiner. Note the attached Office Action or form PTO-152. 

Priority under 35 U.S.C. § 119 

12) D Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 119(a)-(d) or (f). 
a)D All b)D Some * c)D None of: 

1 .□ Certified copies of the priority documents have been received. 

20 Certified copies of the priority documents have been received in Application No. . 

3.Q Copies of the certified copies of the priority documents have been received in this National Stage 
application from the International Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a list of the certified copies not received. 



Attach ment(s) 

1) ^| Notice of References Cited (PTO-892) 4) □ Interview Summary (PTO-41 3) 

2) □ Notice of Draftsperson's Patent Drawing Review (PTO-948) Paper No(s)/Mail Date. . 

3) □ Information Disclosure Statement(s) (PTO/SB/08) 5 ) □ Notice of Informal Patent Application 

Paper No(s)/Mail Date . 6) □ Other: . 



PTOL-T26 d (Rev e 08-06r 



Office Action Summary 



Part of Paper No./Mail Date 20080504 



Application/Control Number: 10/699,102 Page 2 

Art Unit: 2167 

DETAILED ACTION 

1 . This communication is responsive to Amendment, filed 01/28/08. 

Claims 1-214 are pending in this application. Claims 1, 14 are independent claims. In 
the Amendment, claims 1, 14 have been amended. This action is made Final. 

Claim Rejections - 35 USC § 102 

2. The following is a quotation of the appropriate paragraphs of 35 U.S. C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless: 
(e) the invention was described in 

(1) an application for patent, published under section 122(b), by another filed in the United States before 
the invention by the applicant for patent or 

(2) a patent granted on an application for patent by another filed in the United States before the invention 
by the applicant for patent, except that an international application filed under the treaty defined in section 
351(a) shall have the effects for purposes of this subsection of an application filed in the United States only 
if the international application designated the United States and was published under Article 21(2) of such 
treaty in the English language. 

4. Claims 1-8, 10-14 are rejected under 35 U.S.C. 102(e) as being anticipated by Ruttenberg 
et al. (US Patent No. 7,065,586). 

Ruttenberg anticipated independent claims 1, 14 by the following 

As per claim 1, Ruttenberg teaches a method for synchronously transferring an amount 
of local data from a local data storage medium (i.e. a node configured to send data, Summary) to 
a remote data storage medium (i.e. a node configured to receive data, Summary) via a 
communications link having an available bandwidth (i.e. The resources at each node include 
receive bandwidth, transmit bandwidth, and available storage space. The values of the resources 
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vary as a function of time. In one embodiment, the system further includes a node configured to 
send and to receive data, Summary) the local data storage medium associated with a local 
computer system having a local processor sequentially responsive to a plurality of local 
computer programs, the remote data storage medium associated with a remote computer system 
non-redundant of the local computer system and having a remote processor, the method 
comprising: 

evaluating local user conditions associated with transfer of the local data (i.e. a transfer 
module at each node configured to evaluate a data transfer request in view of satisfying 
objectives in accordance with resources at each node, Summary, col. 3, lines 39-50); 

based on the currently available bandwidth (i.e. estimated bandwidths at each node, col. 
3, lines 39-50) and the amount of local data (i.e. the size of the file, col. 6, lines 27-45), 
approximating a transfer time (i.e. estimated transmission times, col. 4, line 41 to col. 5, line 2; 
the size of the file to transfer divided by the available bandwidth, col. 6, lines 27-45) for the local 
data (i.e. Further details of an embodiment of scheduling module 320 are illustrated in FIG. 7 A. 
In this embodiment scheduling module 320 includes a feasibility test 710 and a preemption 
module 740. Feasibility test 710 receives the identities of a sender 220 (or intermediary 230) and 
a receiver 210, the size of the file to transfer, a maximum bandwidth receiver 210 can accept, a 
deadline, and information about available and committed bandwidth resources. Using this 
information feasibility test 710 determines if the transfer is "feasible" or "infeasible. "A basic 
function of feasibility test 710 includes a comparison of the time remaining before the transfer 
deadline with the size of the file to transfer divided by the available bandwidth. In alternative 
embodiments this basic function is augmented by consideration of the total bandwidth that is 
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already committed to other data transfers. Each of the other data transfers considered includes a 
file size and expected transfer rate used to calculate the amount of the total bandwidth their 
transfer will require, col. 6, lines 27-45); 

based on the approximated transfer time (i.e. estimated transmission times, col. 4, line 41 
to col. 5, line 2) the local user conditions, and a status of the local processor, selecting a time (i.e. 
Execution module 340 operates under the guidance of scheduling module 320, but also responds 
to dynamic conditions that are not under the control of scheduling module 320, col. 4, line 41 to 
col. 5, line 2) to transmit the local data to the remote data storage medium (i.e. As illustrated in 
FIG. 7B, an alternative to feasibility test 710 is explicit scheduling routine 720. Explicit 
scheduling routine 720 uses a detailed schedule of uncommitted space and bandwidth resources 
at its node. The detailed schedule includes, for example, available receive bandwidth and space 
as a function of time at receiver 210, and available transmit bandwidth as a function of time at 
sender 220. An embodiment of explicit scheduling routine 720 is illustrated by the following 
example. The scheduled resources are receive bandwidth, transmit bandwidth, and storage 
space. For each scheduled resource, each node (sender 220, receiver 210, and intermediary 
230) is configured with a step function (a function f with a constant value on each of a finite 
number of intervals, e.g.,f(x)=0 for x<0, f(x)=2 for 0<=x<l, and f(x)=3 for 1 <=x<5,f(x)=l for 
5<=x) describing the total amount of the resource as a function of time. Other step functions, for 
example representing the amounts of resources allocated, resources available, and resources 
reserved, are maintained for each scheduled resource throughout the scheduling process. The 
total amount of resources is equal to the sum of the amount of resources allocated, the amount of 
resources available, and the amount of resources reserved, col. 7, lines 1-23); and 
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automatically arranging transfer (i.e. Execution module 340 operates under the guidance 
of scheduling module 320, but also responds to dynamic conditions that are not under the 
control of scheduling module 320, col. 4, line 41 to col. 5, line 2) of the local data to the remote 
data storage medium via the communications link at the selected time (i.e. Admission control 
module 310 receives requests for data transfers from a user, determines the feasibility of the 
requested transfers in view of various objectives, and accepts or denies each request. Admission 
control module 310 queries routing module 330 to identify possible sources of the requested 
data. Scheduling module 320 evaluates the feasibility of a transfer from each of the sources 
identified by routing module 330 and reports back to admission control module 310. Execution 
module 340 manages accepted data transfers and works with other modules to compensate for 
unexpected events that occur during a data transfer. Execution module 340 operates under the 
guidance of scheduling module 320, but also responds to dynamic conditions that are not under 
the control of scheduling module 320. Slack module 350 uses statistical estimates and historical 
performance data to determine an amount of available resources that should be uncommitted 
(reserved) in anticipation of differences between actual (measured) and estimated transmission 
times. Padding module 360 uses statistical models to determine how close to deadlines transfer 
module 240 should attempt to complete transfers. Priority module 370 determines which 
transfers should be allowed to preempt other transfers. Preemption is based on priorities given 
by users, deadlines, confidence of transfer time estimates, or other appropriate criteria. Error 
recovery module 380 assures that the operations controlled by transfer module 240 can be 
returned to a consistent state if an unanticipated event occurs. The functionalities of the modules 
of transfer module 240 are further discussed below, col. 4, line 41 to col. 5, line 2). 
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As per claim 14, Ruttenberg teaches an apparatus for synchronously transferring an 
amount of local data from a local data storage medium (i.e. a node configured to send data, 
Summary) to a remote data storage medium (i.e. a node configured to receive data, Summary) 
via a communications link having an available bandwidth (i.e. The resources at each node 
include receive bandwidth, transmit bandwidth, and available storage space. The values of the 
resources vary as a function of time. In one embodiment, the system further includes a node 
configured to send and to receive data, Summary), the local data storage medium associated with 
a local computer system having a local processor sequentially responsive to a plurality of local 
computer programs, the remote data storage medium associated with a remote computer system 
non-redundant of the local computer system and having a remote processor, the apparatus 
comprising: 

a computer-readable storage medium (i.e. FIG. 2 is a block diagram of a communication 
network 200 according to one embodiment of the invention. Communication network 200 
includes a receiver 210, a sender 220, and intermediaries 230, each coupled via a path 230 to 
network 140. Receiver 210 is a computing device, such as a general purpose computer, a set-top 
box, or an Internet appliance, and includes a local storage 1 70. Sender 220 is a computing 
device, such as a web server or other appropriate electronic networking device. Intermediary 
230 is a computing device, such as a server, that includes local storage 160 for storage of data. 
Receiver 210, sender 220, and intermediaries 230 each include embodiments of a transfer 
module 240. The contents and functionality of transfer module 240 is discussed below in 
conjunction with FIGS. 3 7C, col. 3, lines 10-24); and 
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a processor responsive to the computer-responsive to the computer-readable storage 
medium and to a computer program, the computer program, when loaded into the processor (See 
Fig. 2), operative to perform a method comprising: 

evaluating local user conditions associated with transfer of the local data (i.e. Transfer 
module 240 at each node evaluates a data transfer request in view of satisfying various 
objectives, for example meeting a deadline for completion of the transfer, minimizing the cost of 
bandwidth, a combination of these two objectives, or any other appropriate objectives. In one 
embodiment, transfer module 240 evaluates a data transfer request using known and estimated 
bandwidths at each node and known and estimated storage space at receiver 210 and 
intermediaries 230. Transfer module 240 rejects (denies) a data transfer request if known 
storage space and bandwidth limits suggest that a deadline for the data transfer may not be 
achieved or other objectives cannot be met, col. 3, lines 39-50); 

based on the currently available bandwidth (i.e. estimated bandwidths at each node, col. 
3, lines 39-50) and the amount of local data (i.e. the size of the file, col. 6, lines 27-45), 
approximating a transfer time (i.e. estimated transmission times, col. 4, line 41 to col. 5, line 2; 
the size of the file to transfer divided by the available bandwidth, col. 6, lines 27-45) for the local 
data (i.e. Further details of an embodiment of scheduling module 320 are illustrated in FIG. 7 A. 
In this embodiment scheduling module 320 includes a feasibility test 710 and a preemption 
module 740. Feasibility test 710 receives the identities of a sender 220 (or intermediary 230) and 
a receiver 210, the size of the file to transfer, a maximum bandwidth receiver 210 can accept, a 
deadline, and information about available and committed bandwidth resources. Using this 
information feasibility test 710 determines if the transfer is "feasible" or "infeasible. "A basic 
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function of feasibility test 710 includes a comparison of the time remaining before the transfer 
deadline with the size of the file to transfer divided by the available bandwidth. In alternative 
embodiments this basic function is augmented by consideration of the total bandwidth that is 
already committed to other data transfers. Each of the other data transfers considered includes a 
file size and expected transfer rate used to calculate the amount of the total bandwidth their 
transfer will require, col. 6, lines 27-45); 

based on the approximated transfer time (i.e. estimated transmission times, col. 4, line 41 
to col. 5, line 2) the local user conditions, and a status of the local processor, selecting a time (i.e. 
Execution module 340 operates under the guidance of scheduling module 320, but also responds 
to dynamic conditions that are not under the control of scheduling module 320, col. 4, line 41 to 
col. 5, line 2) to transmit the local data to the remote data storage medium (i.e. As illustrated in 
FIG. 7B, an alternative to feasibility test 710 is explicit scheduling routine 720. Explicit 
scheduling routine 720 uses a detailed schedule of uncommitted space and bandwidth resources 
at its node. The detailed schedule includes, for example, available receive bandwidth and space 
as a function of time at receiver 210, and available transmit bandwidth as a function of time at 
sender 220. An embodiment of explicit scheduling routine 720 is illustrated by the following 
example. The scheduled resources are receive bandwidth, transmit bandwidth, and storage 
space. For each scheduled resource, each node (sender 220, receiver 210, and intermediary 
230) is configured with a step function (a function f with a constant value on each of a finite 
number of intervals, e.g.,f(x)=0 for x<0,f(x)=2 for 0<=x<l, and f(x)=3 for 1 <=x<5,f(x)=l for 
5<=x) describing the total amount of the resource as a function of time. Other step functions, for 
example representing the amounts of resources allocated, resources available, and resources 
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reserved, are maintained for each scheduled resource throughout the scheduling process. The 
total amount of resources is equal to the sum of the amount of resources allocated, the amount of 
resources available, and the amount of resources reserved, col. 7, lines 1-23); and 

automatically arranging transfer (i.e. Execution module 340 operates under the guidance 
of scheduling module 320, but also responds to dynamic conditions that are not under the 
control of scheduling module 320, col. 4, line 41 to col. 5, line 2) of the local data to the remote 
data storage medium via the communications link at the selected time (i.e. Admission control 
module 310 receives requests for data transfers from a user, determines the feasibility of the 
requested transfers in view of various objectives, and accepts or denies each request. Admission 
control module 310 queries routing module 330 to identify possible sources of the requested 
data. Scheduling module 320 evaluates the feasibility of a transfer from each of the sources 
identified by routing module 330 and reports back to admission control module 310. Execution 
module 340 manages accepted data transfers and works with other modules to compensate for 
unexpected events that occur during a data transfer. Execution module 340 operates under the 
guidance of scheduling module 320, but also responds to dynamic conditions that are not under 
the control of scheduling module 320. Slack module 350 uses statistical estimates and historical 
performance data to determine an amount of available resources that should be uncommitted 
(reserved) in anticipation of differences between actual (measured) and estimated transmission 
times. Padding module 360 uses statistical models to determine how close to deadlines transfer 
module 240 should attempt to complete transfers. Priority module 370 determines which 
transfers should be allowed to preempt other transfers. Preemption is based on priorities given 
by users, deadlines, confidence of transfer time estimates, or other appropriate criteria. Error 
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recovery module 380 assures that the operations controlled by transfer module 240 can be 
returned to a consistent state if an unanticipated event occurs. The functionalities of the modules 
of transfer module 240 are further discussed below, col. 4, line 41 to col. 5, line 2). 

As per claim 2, Ruttenberg teaches a computer-readable medium encoded with a 
computer program which, when loaded into a processor, implements the method of claim 1 (i.e. 
FIG. 2 is a block diagram of a communication network 200 according to one embodiment of the 
invention. Communication network 200 includes a receiver 210, a sender 220, and 
intermediaries 230, each coupled via a path 230 to network 140. Receiver 210 is a computing 
device, such as a general purpose computer, a set-top box, or an Internet appliance, and 
includes a local storage 1 70. Sender 220 is a computing device, such as a web server or other 
appropriate electronic networking device. Intermediary 230 is a computing device, such as a 
server, that includes local storage 160 for storage of data. Receiver 210, sender 220, and 
intermediaries 230 each include embodiments of a transfer module 240. The contents and 
functionality of transfer module 240 is discussed below in conjunction with FIGS. 3 7C, col. 3, 
lines 10-24). 

As per claim 3, Ruttenberg teaches the computer-readable medium according to claim 2, 
wherein the computer program comprises one of the plurality of local computer-program, and the 
processor comprise the local processor (i.e. FIG. 2 is a block diagram of a communication 
network 200 according to one embodiment of the invention. Communication network 200 
includes a receiver 210, a sender 220, and intermediaries 230, each coupled via a path 230 to 
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network 140. Receiver 210 is a computing device, such as a general purpose computer, a set-top 
box, or an Internet appliance, and includes a local storage 1 70. Sender 220 is a computing 
device, such as a web server or other appropriate electronic networking device. Intermediary 
230 is a computing device, such as a server, that includes local storage 160 for storage of data. 
Receiver 210, sender 220, and intermediaries 230 each include embodiments of a transfer 
module 240. The contents and functionality of transfer module 240 is discussed below in 
conjunction with FIGS. 3 7C, col. 3, lines 10-24). 

As per claim 4, Ruttenberg teaches the computer-readable medium according to claim 2, 
wherein the processor comprises the remote processor (i.e. FIG. 2 is a block diagram of a 
communication network 200 according to one embodiment of the invention. Communication 
network 200 includes a receiver 210, a sender 220, and intermediaries 230, each coupled via a 
path 230 to network 140. Receiver 210 is a computing device, such as a general purpose 
computer, a set-top box, or an Internet appliance, and includes a local storage 1 70. Sender 220 
is a computing device, such as a web server or other appropriate electronic networking device. 
Intermediary 230 is a computing device, such as a server, that includes local storage 160 for 
storage of data. Receiver 210, sender 220, and intermediaries 230 each include embodiments of 
a transfer module 240. The contents and functionality of transfer module 240 is discussed below 
in conjunction with FIGS. 3 7C, col. 3, lines 10-24). 

As per claim 5, Ruttenberg teaches the method according to claim 1, further comprising: 
automatically transmitting the local data to the remote data storage medium at the selected time 
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(i.e. Execution module 340 operates under the guidance of scheduling module 320, but also 
responds to dynamic conditions that are not under the control of scheduling module 320, col. 4, 
line 41 to col. 5, line 2). 

As per claim 6, Ruttenberg teaches the method according to claim 1, further comprising: 
automatically arranging for interruption of transfer of the local data bases on the status of the 
local processor (i.e. Error recovery module 380 also minimizes the amount of extra data 
transferred in completing interrupted transfers and the number of accepted requests that are 
canceled as a result of failures and timeouts. Data is stored in each node regarding requests 
accepted by scheduling module 320, resource allocation, the state of each transfer in progress, 
waiting lists 735 (if these are supported), and any state required to describe routing policies 
(e.g., proxy lists). Error recovery module 380 uses this information to restart data transfers at 
each node, col. 12, lines 38-54). 

As per claim 7, Ruttenberg teaches the method according to claim 6, further comprising: 
automatically interrupting transfer of the local data based on the status of the local processor (i.e. 
Error recovery module 380 also minimizes the amount of extra data transferred in completing 
interrupted transfers and the number of accepted requests that are canceled as a result of 
failures and timeouts. Data is stored in each node regarding requests accepted by scheduling 
module 320, resource allocation, the state of each transfer in progress, waiting lists 735 (if these 
are supported), and any state required to describe routing policies (e.g., proxy lists). Error 
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recovery module 380 uses this information to restart data transfers at each node, col. 12, lines 
38-54). 

As per claim 8, Ruttenberg teaches the method according to claim 6, wherein the status 
of the local processor is inferred from one of: status of a display device, a status of a memory; a 
configured processor utilization; and a time since a last interactive use of the local computer 
system (i.e. Execution module 340 operates under the guidance of scheduling module 320, but 
also responds to dynamic conditions that are not under the control of scheduling module 320. 
Slack module 350 uses statistical estimates and historical performance data to determine an 
amount of available resources that should be uncommitted (reserved) in anticipation of 
differences between actual (measured) and estimated transmission times. Padding module 360 
uses statistical models to determine how close to deadlines transfer modide 240 should attempt 
to complete transfers. Priority module 370 determines which transfers should be allowed to 
preempt other transfers. Preemption is based on priorities given by users, deadlines, confidence 
of transfer time estimates, or other appropriate criteria. Error recovery module 380 assures that 
the operations controlled by transfer module 240 can be returned to a consistent state if an 
unanticipated event occurs. The functionalities of the modules of transfer module 240 are further 
discussed below, col. 4, line 41 to col. 5, line 2). 

As per claim 10, Ruttenberg teaches the method according to claim 6, further 
comprising: after automatically arranging for interruption of transfer of the local data, 
automatically arranging for resumption of transfer of the local data based on the status of the 
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local processor (i.e. Error recovery module 380 also minimizes the amount of extra data 
transferred in completing interrupted transfers and the number of accepted requests that are 
canceled as a result of failures and timeouts. Data is stored in each node regarding requests 
accepted by scheduling module 320, resource allocation, the state of each transfer in progress, 
waiting lists 735 (if these are supported), and any state required to describe routing policies 
(e.g., proxy lists). Error recovery module 380 uses this information to restart data transfers at 
each node, col. 12, lines 38-54). 

As per claim 11, Ruttenberg teaches the method according to claim 10, further 
comprising: automatically resuming transfer of the local data based on the status of the local 
processor (i.e. Error recovery module 380 also minimizes the amount of extra data transferred in 
completing interrupted transfers and the number of accepted requests that are canceled as a 
result of failures and timeouts. Data is stored in each node regarding requests accepted by 
scheduling module 320, resource allocation, the state of each transfer in progress, waiting lists 
735 (if these are supported), and any state required to describe routing policies (e.g., proxy 
lists). Error recovery module 380 uses this information to restart data transfers at each node, 
col. 12, lines 38-54). 

As per claim 12, Ruttenberg teaches the method according to claim 1, wherein the local 
user conditions comprise one of: a location of the local data; a preferred transfer time; a file 
extension associated with the local data; and a status of the communication link (i.e. Execution 
module 340 operates under the guidance of scheduling module 320, but also responds to 
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dynamic conditions that are not under the control of scheduling module 320. Slack module 350 
uses statistical estimates and historical performance data to determine an amount of available 
resources that should be uncommitted (reserved) in anticipation of differences between actual 
(measured) and estimated transmission times. Padding module 360 uses statistical models to 
determine how close to deadlines transfer module 240 should attempt to complete transfers. 
Priority module 370 determines which transfers should be allowed to preempt other transfers. 
Preemption is based on priorities given by users, deadlines, confidence of transfer time 
estimates, or other appropriate criteria. Error recovery module 380 assures that the operations 
controlled by transfer module 240 can be returned to a consistent state if an unanticipated event 
occurs. The functionalities of the modules of transfer module 240 are further discussed below, 
col. 4, line 41 to col. 5, line 2). 

As per claim 13, Ruttenberg teaches the method according to claim 1, wherein the 
remote processor and the local processor are under independent control (i.e. FIG. 2 is a block 
diagram of a communication network 200 according to one embodiment of the invention. 
Communication network 200 includes a receiver 210, a sender 220, and intermediaries 230, 
each coupled via a path 230 to network 140. Receiver 210 is a computing device, such as a 
general purpose computer, a set-top box, or an Internet appliance, and includes a local storage 
1 70. Sender 220 is a computing device, such as a web server or other appropriate electronic 
networking device. Intermediary 230 is a computing device, such as a server, that includes local 
storage 160 for storage of data. Receiver 210, sender 220, and intermediaries 230 each include 
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embodiments of a transfer module 240. The contents and functionality of transfer module 240 is 
discussed below in conjunction with FIGS. 3 7C, col. 3, lines 10-24). 

Claim Rejections - 35 USC §103 

4. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

This application currently names joint inventors. In considering patentability of the claims 
under 35 U.S.C. 103(a), the examiner presumes that the subject matter of the various claims 
was commonly owned at the time any inventions covered therein were made absent any 
evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1 .56 to point 
out the inventor and invention dates of each claim that was not commonly owned at the time 
a later invention was made in order for the examiner to consider the applicability of 35 
U.S.C. 103(c) and potential 35 U.S.C. 102(e), (f) or (g) prior art under 35 U.S.C. 103(a). 

5. Claim 9 is rejected under 35 U.S.C. 103(a) as being unpatentable over Ruttenberg et al. 
(US Patent No. 7,065,586), in view of Roberts et al. (US Patent No. 6,920,1 10). 

As per claim 9, Ruttenberg does not specifically teach the method according to claim 8, 
wherein the status of the display device comprises activation of a screen-saver. 

Roberts teaches this limitation (i.e. The relatively low level of actual network bandwidth 
utilization shown from T.sub.5 through T.sub.8 (FIG. 4) is sometimes referred to as "network 
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idle. " This concept differs from "machine idle, " which occurs when a PC user is not currently 
using the keyboard or mouse. If the machine remains idle for a period of time, a screen saver 
may be invoked, col. 7, line 59 to col. 8, line 12). 

It would have been obvious to one of ordinary skill of the art having the teaching of 
Ruttenberg, and Roberts at the time the invention was made to modify the system of Ruttenberg 
to include the limitations as taught by Roberts. One of ordinary skill in the art would be 
motivated to make this combination in order to transfer a set of data, such as a software update, 
over a network at a time when the network utilization is relatively low in view of Roberts (col. 7, 
line 59 to col. 8, line 12), as doing so would give the added benefit of allowing effective 
utilization of the network bandwidth while also allowing an adaptation that supports a degree of 
responsiveness both on fast and slow networks, as taught by Roberts (Summary). 

Response to Arguments 

6. With respect to claims 1-14, Applicants have amended the independent claim 1, 14 to 
recite "based on the currently available bandwidth and the amount of local data, 
approximating a transfer time for the local data "; however, upon further consideration, a new 
ground(s) of rejection is made in view of newly found prior art. 

Conclusion 

7. Applicant's amendment necessitated the new ground(s) of rejection presented in this 
Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 
Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). 
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A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1 .136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Miranda Le whose telephone number is (571) 272-41 12. The 
examiner can normally be reached on Monday through Friday from 8:30 AM to 5:00 PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, John R. Cottingham, can be reached on (571) 272-7079. The fax number to this Art 
Unit is (571)-273-8300. 

Any inquiry of a general nature or relating to the status of this application should be 
directed to the Group receptionist whose telephone number is (571) 272-2100. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http ://pair-direct.uspto . gov . Should you have questions on access to the Private 
PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 



/Miranda Le/ 

Primary Examiner, Art Unit 2167 



